Virtual drives in an automated storage library

ABSTRACT

A method for servicing a mount request in an automated storage library in which all of the peripheral storage devices therein are occupied and which permits an active data storage medium to be temporarily demounted and subsequently remounted in any subsequently available peripheral storage device is disclosed. To service a mount request requiring that a data storage medium be demounted, the access information for the data storage medium to be demounted is first retained. After demounting and servicing of the mount request, the retained access information is used to permit remounting of the previously mounted data storage medium in any subsequently available peripheral storage device, thereby minimizing the risk of delay in remounting. The method also allows for optional parameters to prevent temporary demounting in an automated storage library, or to prevent temporary demounting of particular data storage media. An automated storage library and program product employing the method are also disclosed.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates to a machine-executed method for servicing amount request in an automated storage library in which all of theperipheral storage devices therein are occupied, and an automatedstorage library and program product therefor. More particularly, themethod allows an active volume to be temporarily demounted andsubsequently remounted in any subsequently available peripheral storagedevice.

2. Description of the Related Art

Modern computers require a host processor including one or more centralprocessing units and a memory facility. The processor manipulates datastored in the memory according to instructions provided to it. Thememory must therefore be capable of storing data required by theprocessor and transferring that data to the processor at a rate capableof making the overall operation of the computer feasible. The cost andperformance of computer memory is thus critical to the commercialsuccess of a computer system.

Because today's computers require large quantities of data storagecapacity, computer memory is available in many forms. A fast butexpensive form of memory is main memory, typically comprised ofmicrochips. Other available forms of memory are known as peripheralstorage devices and include magnetic direct access storage devices(DASD), magnetic tape storage devices, and optical recording devices.These types of memory actually store data on storage media therein. Eachof these other types of memory has a greater storage density and lowercost than main memory. However, these other memory devices do notprovide the performance provided by main memory. For example, the timerequired to properly position the tape or disk beneath the read/writemechanism of the drive cannot compare with the rapid, purely electronicdata transfer rate of main memory.

It is inefficient to store all of the data in a computer system on but asingle type of memory device. Storing all of the data in main memory istoo costly and storing all of the data on one of the peripheral storagedevices reduces performance. Thus, a typical computer system includesboth main memory and one or more types of peripheral storage devicesarranged in a data storage hierarchy. The data storage hierarchyarrangement is tailored to the performance and cost requirements of theuser. In such a hierarchy, main memory is often referred to as primarydata storage, the next level of the hierarchy is often referred to assecondary data storage, and so on. Generally, the highest level of thehierarchy has the lowest storage density capability, highest performanceand highest cost. As one proceeds down through the hierarchy, storagedensity generally increases, performance generally decreases, and costgenerally decreases. By transferring data between different levels ofthe hierarchy as required, the cost of memory is minimized andperformance is maximized. Data is thus stored in main memory only solong as it is expected to be required by the processor. The hierarchymay take many forms, include any number of data storage or memorylevels, and may be able to transfer data directly between any twodistinct memory levels. The transfer of data may employ I/O channels,controllers, or cache memories as is well known in the art.

Images may be included in engineering drawings, financial and insurancedocuments, medical charts and records, etc. Until recently, it was notpossible to store image data in memory in a cost effective manner.Images can take many forms, and therefore cannot be encoded into thebinary 0's and 1's of computers as easily and compactly as text.Engineering drawings are typically stored on paper, microfilm, ormicrofiche requiring manual retrieval when access to a drawing isnecessary. The same is true for X-rays and other diagnostic medicalimages, bank checks used in transactions between financial institutions,insurance records, images in FAX documents and so on. Thus, despitemodern computers, it is estimated that most of the world's data is stillstored on paper. The cost of filing, storing, and retrieving such paperdocuments including image data is escalating rapidly. It is no longeracceptable to maintain rooms or warehouses stocked full of documentswhich must be retrieved manually when access thereto is required.Optical scanners are now capable of converting images into machinereadable form for storage on peripheral storage devices, but the storagespace required for the image data--although significantly less than thatrequired for paper documents--is still quite large. Numerous disks ortapes are required for most business applications. Automated storagelibraries have thus been developed to manage the storage of such disksor tapes.

Automated storage libraries include a plurality of storage cells orslots for retaining data storage media, such as magnetic tapes, magneticdisks, or optical disks, a robotic picker mechanism, and one or moreinternal peripheral storage devices. Each data storage medium may becontained in a cassette or cartridge housing for easier handling by thepicker. The picker operates on command to transfer the data storagemedia between the storage cells and the internal peripheral storagedevices without manual assistance. An internal peripheral storage devicehaving a storage medium mounted therein is referred to as "occupied".Once a data storage medium is mounted in an internal peripheral storagedevice, data may be written to or read out from that medium for as longas the system so requires. Data is stored on a medium in the form of oneor more files, each file being a logical data set. A file is considered"open" when it is reserved for access by a particular user and thestorage medium upon which it resides is mounted in a peripheral storagedevice and ready to be accessed. For example, in an optical disklibrary, a file is open if it is reserved for exclusive access and thedisk on which it resides is mounted in a drive and spinning. Aperipheral storage device having a storage medium therein with an openfile is referred to as "active", regardless of whether actual electronictransfer is occurring. A peripheral storage device is also active if thestorage medium mounted therein is undergoing access under any standardoperating system command not requiring that a file be open, such as adirectory read. An active storage medium is generally considered to beone in an active peripheral storage device. The internal peripheralstorage devices and storage cells may be considered distinct levels of adata storage hierarchy. In addition, data storage media in shelf storage(i.e. not in the storage cells, but instead outside the reach of therobotic picker without manual intervention) may be considered yetanother level of a data storage hierarchy.

Automated storage libraries may also include one or more externalperipheral storage devices. An external peripheral storage device is aperipheral storage device which, unlike internal peripheral storagedevices, is not accessible by the picker but must instead be loaded andunloaded manually. External peripheral storage devices may be includedin libraries as a convenience to the library operator. A shelf storagemedium requiring brief access will not have to be inserted into thelibrary and retrieved by the picker for mounting in one of the internalperipheral storage devices. External peripheral storage devices may alsobe considered explicitly mentioned herein, "peripheral storage devices"hereinafter refers to internal peripheral storage devices only.

Several automated storage libraries are known. IBM Corporationintroduced the 3850 Mass Storage Subsystem for the storage and retrievalof magnetic tape modules in the 1970's. More recently, several firmshave introduced automated storage libraries for magnetic tape cartridgesand optical disks. For example, magnetic tape cartridge libraries aredisclosed in U.S. Pat. Nos. 4,654,727 and 4,864,438, and 4,864,511.Examples of optical disk libraries can be found in U.S. Pat. Nos.4,271,489, 4,527,262, 4,614,474, and 4,766,581. The robotic pickermechanisms of these libraries include one or more grippers, each grippercapable of handling one data storage medium at a time. The '489, '262,'474 patents disclose robotic pickers having but a single gripper andthe '727, '438, '511 and '581 patents disclose robotic pickers havingmultiple grippers. IBM also markets the 9246 Optical Library Unit whichis a two gripper library.

Normally, a data storage medium or data volume in a peripheral storagedevice is demounted immediately after the need for access to it ceasesor upon the need to mount a new data storage medium therein. Any accessinformation is lost when the data storage medium is demounted. Insystems retaining such access information to make remounting of the datastorage medium more convenient, the data storage medium must be mountedin the same peripheral storage device in which it was previouslymounted. In automated storage libraries, such tying of a data storagemedium to a particular peripheral storage device therein cansignificantly impact performance. If the mount is tied to a particularperipheral storage device, heavy use of such peripheral storage deviceafter demounting can prohibitively delay remounting.

SUMMARY OF THE INVENTION

In view of the foregoing, it is the principal object of this inventionto provide an improved method for managing an automated storage library,and an automated storage library and program product therefor.

Yet another object of this invention is a method for servicing a mountrequest in an automated storage library, and an automated storagelibrary and program product therefor.

Still another object of this invention is a method for temporarilydemounting a data storage medium in an automated storage library with aminimum risk of delay in remounting, and an automated storage libraryand program product therefor.

These and other objects of this invention are accomplished by a methodfor servicing a mount request in an automated storage library in whichall of the peripheral storage devices therein are occupied and whichpermits an active data storage medium to be temporarily demounted andsubsequently remounted in any subsequently available peripheral storagedevice. To service a mount request requiring that a data storage mediumbe demounted, the access information for the data storage medium to bedemounted is first retained. After demounting and servicing of the mountrequest, the retained access information is used to permit remounting ofthe previously mounted data storage medium in any subsequently availableperipheral storage device, thereby minimizing the risk of delay inremounting. The method also allows for optional parameters to preventtemporary demounting in an automated storage library, or to preventtemporary demounting of particular data storage media. An automatedstorage library and program product for employing the method are alsodisclosed.

The foregoing and other objects, features, and advantages, of theinvention will be apparent from the following more particulardescription of the preferred embodiment of the invention, as illustratedin the accompanying drawing.

BRIEF DESCRIPTION OF THE DRAWING

FIG. 1 is a front, perspective cut-away view of an automated opticaldisk library of the present invention.

FIG. 2 is the same view as in FIG. 1 except that the console panel hasbeen swung aside and the fan has been removed.

FIG. 3 is a rear, perspective cut-away view of the automated opticaldisk library of FIGS. 1 and 2.

FIG. 4 is a magnified view of the robotic picker and gripper of FIG. 3.

FIG. 5 is a schematic diagram of the optical disk library hardware ofFIGS. 1-4.

FIG. 6 is a schematic block diagram of the system controller of theoptical disk library of FIGS. 1-5.

FIG. 7 is a sample path specification for a file in the optical disklibrary of FIGS. 1-5.

FIG. 8 is a schematic block diagram of the internal data structurescreated during initialization.

FIG. 9 is a flow chart of the operations of the system controller of anoptical disk library in translating a network request received at itsupper interface into SCSI command packets at its lower interfaceaccording to the present invention.

FIG. 10 is a flow chart of the high level operations of FIG. 9 for arepresentative IFS entry point.

FIG. 11 is a flow chart of the PARSE routine called in FIG. 10.

FIG. 12 is a flow chart of the READY VOLUME routine called in FIG. 10.

FIG. 13 is a flow chart of the IN CELL routine called in FIG. 12.

FIG. 14 is a flow chart of the IN DRIVE routine called in FIG. 12.

FIG. 15 is a flow chart of the SWAP routine called in FIG. 12.

FIG. 16 is a flow chart of the ALLOCATE routine called in theaforementioned routines.

FIG. 17 is a flow chart of the FORCE ALLOCATE routine called in theaforementioned routines.

FIG. 18 is a flow chart of the RELEASE VOLUME routine called in FIG. 10.

FIG. 19 is a flow chart of the IDLE DEMOUNT routine according to oneembodiment of the present invention.

DESCRIPTION OF THE PREFERRED EMBODIMENT

Referring now more particularly to the drawing, like numerals denotelike features and structural elements in the various figures. Theautomated storage library of the invention will be described as embodiedin an optical disk library. Referring to FIGS. 1-4, various views ofsuch an optical disk library is shown. The library 1 includes a housing2 enclosing most of the working parts of the library and having frontand rear door panels (not shown) for interior access. Library 1 furtherincludes a plurality of optical disk storage cells 3 and a plurality ofinternal optical disk drives 4. Each storage cell 3 is capable ofstoring one optical disk having data recorded on one or both sidesthereof. The data stored on each side of a disk is referred to as a"volume". In the preferred embodiment, library 1 includes 144 storagecells 3 arranged in two 72 storage cell columns and up to four opticaldisk drives 4. The optical disks may include ablative, phase-change,magneto-optic, or any other optical recording layers and may beread-only, write-once, or rewritable, as is known, so long as they arecompatible with optical disk drives 4. In addition, the optical disksmay be recorded in a spiral or concentric track pattern. The preciserecording format is not part of the subject invention and may be anyknown in the art. A robotic picker 5 includes a single gripper 6 capableof accessing an optical disk in any of storage cells 3 or drives 4 andtransferring such optical disks therebetween. In the preferredembodiment, the optical disks are configured in cartridges for easyhandling by gripper 6 and are 5 and 1/4 inch form factor disks, but inalternative embodiments could be any size compatible with drives 4 andgripper 6.

Although the front face of housing 2 is not shown in FIG. 1, certainportions of library 1 protrude through such front face of housing 2 foroperator access. These portions are part of a console door 7 and includeall or part of a power indicator/switch 8, an entry/exit slot 9, anexternal optical disk drive 10, a console 11, and a keyboard 12. Consoledoor 7 can be swung aside to allow access therebehind, when necessary,as shown in FIG. 2. Slot 9 is used for inserting optical disks to orremoving optical disks from library 1. Commands may be provided by anoperator to library 1, via keyboard 12, to have picker 5 receive anoptical disk inserted at slot 9 and transport such disk to a storagecell 3 pr drive 4, or to have picker 5 retrieve an optical disk from astorage cell 3 or drive 4 and deliver such disk to slot 9 for removalfrom library 1. Console 11 allows an operator to monitor and controlcertain operations of library 1 without seeing inside housing 2.External optical disk drive 10, unlike drives 4, cannot be accessed bygripper 6. Drive 10 must instead be loaded and unloaded manually.Library 1 also includes an optical disk drive exhaust fan 14, anexternal disk drive exhaust fan 15, and power supplies 16.

Once library 1 is powered on, commands received at keyboard 12 areforwarded to a system controller 17. In the preferred embodiment, systemcontroller 17 is an IBM PS/2 Model 80 personal computer using the OS/2operating system. The IBM PS/2 model 80 personal computer includes mainmemory and one or more storage media, such as those in fixed or floppydisk drives. System controller 17 issues instructions to drives 4,external drive 10, and picker 5 as will be described. Drive controllercards 13 and picker 5 controller card 18 convert known small computersystem interface (SCSI) command packets issued by system controller 17into the electromechanical action of drives 4, external drive 10, andpicker 5. The movement of picker 5 within library 1 is X-Y in nature.Movement in the vertical direction is driven by a vertical directionmotor 19 and movement in the horizontal direction is driven by ahorizontal direction motor 20. Motor 19 turns a lead screw 21 to movepicker 5 vertically. Motor 20 turns belts 22 and 23 to move picker 5horizontally. In addition, picker 5 may be rotated to bring either sideof an optical disk within the grasp of gripper 6 to an upright position.The remaining physical features of library 1 are not shown in thedrawing, or are shown but not labeled for the purpose of simplification,but are well known.

Referring to FIG. 5, the system connections of library 1 will now bedescribed. System controller 17 is attached to one or more host/systemprocessors 30 to receive input therefrom and to transmit output thereto.System processor 30 can be a host central processing unit (CPU), such asan IBM 3090 mainframe processor using the MVS or VM operating system ofIBM AS/400 midrange computer using the OS/400 or AIX operating system,or a network of processors, such as IBM PS/2 personal computers usingthe OS/2 or DOS operating system and arranged in a local area network(LAN). The connections to system processor 30 are not shown, but arewell known. If system processor 30 is an IBM 3090 mainframe processor,the connection could be made using an IBM System/370 channel attachmentaccording to the interface described in IBM Document #SA22-7091-00, "IBMChannel-to-Channel Adapter", June, 1983, IBM Document #GA22-6974-09,"IBM System/360 and System 370 I/O Interface Channel to Control UnitOriginal Equipment Manufacturers Information", February, 1988, and IBMDocument #SA22-7085-01, "IBM System/370 Extended Architecture Principlesof Operation", January, 1987, each of which are hereby incorporated byreference. If system processor 30 is an IBM AS/400 midrange computer,the connection could be made using a direct, SCSI interface attachmentwherein library 1 is directly controlled by the host system according toANSI standard X3T9.2/86-109 rev. 5, hereby incorporated by reference. Ifsystem processor 30 is a plurality of IBM PS/2 personal computersarranged in a LAN, the connection could be made using the NETBIOScontrol program interface of the IBM Token Ring Network LAN attachment,according to the protocols described in IBM Document #SC21-9526,"Distributed Data Management Level 2.0 Architecture Reference", March,1989, hereby incorporated by reference. The preferred embodiment oflibrary 1 will hereinafter be described as used as a file server in aLAN environment wherein library 1 appears to the system as a shared,general storage device.

System controller 17 is attached to drives 4, picker 5, and externaloptical disk drive 10 via known single-ended SCSI connections, includingSCSI bus 31. In an alternative embodiment, system controller 17 may besimilarly connected to another physical box to direct the operations ofsuch other box, not shown in the drawing. The other box would beessentially identical to that shown in FIGS. 1-4, except that the otherbox would not physically include a system controller therein, but wouldinstead be controlled by system controller 17 via SCSI bus 32. Thelogical subsystem including both physical boxes, one box with a systemcontroller and one box without a system controller, is considered to bea single library. In addition, for use in certain environments, twosystem controllers can be connected via an RS-232 interface (not shown)to create a library including two boxes with system controllers and twoboxes without system controllers, and so on.

Referring to FIG. 6, a functional component level description of systemcontroller 17 will now be provided. Generally, system controller 17 isdesigned to support major library functions such as creating anddeleting files, writing to and reading from the files, moving opticaldisks between storage cells 3, drives 4, and slot 9, and providingstatistics on usage and errors. Volumes in the library appear assubdirectories in the root directory of a single drive. Labels assignedto each volume represent the subdirectory name. System processor 30 isable to read the root directory but cannot store files in the rootdirectory. Any paths accessed on a volume appear as paths under thesubdirectory element that represents the volume label.

Standard path protocol known in the personal computer environment isused to access files in library 1. The path format is shown in FIG. 7and includes path elements 35-37 and 39. Of the path elements, "d:" isthe designator 35 for library 1, "volid" is the volume label 36,"path1/path2" etc. is the normal subdirectory path specification 37, and"file.ext" is the filename and extension 39. Backslashes are used toseparate path elements. Designator 35 for library 1 is a letter andcolon as is used for any peripheral storage device in the personalcomputer environment, such as the commonly used "c:" for a fixed diskdrive. Volume label 36 appears as a subdirectory element in the rootdirectory of the designated hardware. Because the first apparentsubdirectory element is actually the volume identifier and the remainingsubdirectory elements are the actual path 37, library 1 appears tosystem processor 30 as does any single, peripheral storage device.Library 1 requires no instruction as to the physical location of thevolume within library 1, the drive 4 in which to mount the volume, etc.Instead, system controller 17 makes all such determinations and directsthe appropriate actions. Library management is thus transparent tousers.

A generic library file server (GLFS) 50 controls the library with a setof generic, intermediate hardware commands through a formally definedinterface which will be described later herein. Data is manipulated byGLFS 50 at the logical record level allowing for data access inquantities spanning from a single byte to complete, variable length dataobjects. An operating system 51 mediates the flow of control and directsincoming operating system commands from the external interfaces into thelibrary subsystem. Operating system 51 can be any of several knownoperating systems and in the preferred embodiment is the OS/2 operatingsystem. The use of the OS/2 operating system generally allows forcontrol of library 1 through standard fixed disk operating systemcommands. Library control is directed through a unique command,DosFsCtl. This command is used to support initialization, entry/exit ofan optical disk from library 1, read/store the library map file,mount/demount an optical disk in drive 10, enable/disable virtual driveoption, etc. Drive control is directed through a unique command,DosDevIOCtl. The remainder of the programmed control for library 1 isretained in microcode which is uploaded into the main memory of systemcontroller 17 from a storage medium resident therein at initialization.In alternative embodiments, some function required to support themicroprogrammed control may also be provided as a utility to theoperating system running in system processor 30.

The OS/2 operating system includes several advanced operating systemconcepts integral to system controller 17. These advanced concepts aredynamic link libraries, installable file systems, and multitasking. Adynamic link library (DLL) is a file containing a set of functions eachof which may be dynamically loaded as needed. Normally, a program iscompiled and linked with the compiled program code of all of thefunctions the program might invoke before it can be executed. A DLLpermits a program to invoke functions compiled and linked intoindependent modules of program code. OS/2 includes a set of DLL modulesthat can be invoked as required. Using a custom DLL module, OS/2 can bemade to control non-standard storage devices. The custom DLL module isknown as an installable file system (IFS). Each function supported by anIFS is known as an entry point. For additional information oninstallable file systems, see IBM Document #G362-0001-03, "IBM PersonalSystems Developer", Fall, 1989, hereby incorporated by reference. In thepreferred embodiment, GLFS 50 is implemented as an IFS to the OS/2operating system with prescribed entry points.

Another important aspect of the OS/2 operating system is multitasking.Multitasking is the ability of a system to run multiple programsconcurrently. The system processor's time is apportioned amongst taskseach appearing to be running as if no other tasks are present. Aseparate environment is maintained for each task; memory and registercontents for each task are isolated to avoid interference with eachother. A task and its associated environment is referred to as a"thread". Programs can include a code area and a data area in the mainmemory of the IBM PS/2 model 80 personal computer. The code area is thesection of memory containing the instructions being executed for anygiven thread. The data area is the section of memory (or registers) thatis manipulated during execution of the instructions. Because the samecode area may be used for several threads, each thread may point to thesame code area for execution but includes its own isolated data area.

The upper interface translator 80 is responsible for translating betweenupper interface commands and those of GLFS 50. The lower interfacetranslator 90 is responsible for translating between the commands issuedby GLFS 50 and those of the lower interface. Translators 80 and 90 areeach implemented as distinct linkable modules with clearly definedinterfaces, thereby permitting easy attachment of library 1 to new upperand lower interfaces. The only impact of attachment to a new interfaceis the creation of a new portion of translators 80 and 90--the genericnature of GLFS 50 allows it to remain unchanged.

The upper interfaces of library 1 include the library configuration,map, and system performance files, console 11 (and keyboard 12), and thenetwork interface. The library configuration, library map, and systemperformance files are not shown in the drawing, but are stored on thefixed disk drive of system controller 17. These files are maintained bythe library operator or maintenance personnel. The library configurationfile lists various characteristics of the hardware configuration oflibrary 1, such as the number of physical boxes in library 1, the numberof drives 4 and 10 in each physical box, whether a drive is an internaldrive 4 or an external drive 10, the number of storage cells 3 in eachphysical box, the SCSI addresses of each picker 5 and drive 4 or drive10, etc. The library map file lists various characteristics of theoptical disks in library 1, such as the volume label of each opticaldisk in library 1, the address of the home storage cell for each opticaldisk in library 1, free space information for each optical disk, andcertain usage statistics for each optical disk, such as the number ofmounts, the date and time of last access, etc. System controller 17 usesthe library configuration and map files to identify the number andarrangement of resources in the library, and adjusts the files as thestatus of the resources in library 1 changes. The system performancefile lists operator specified parameters such as the virtual driveoption parameter U, minimum virtual drive eligibility time V, minimumdemount eligibility time W, preemptive demount eligibility time X, andidle demount time Y, all of which are defined later herein. Console 11is used to exhibit the ongoing status of the library components and makecommands and utility functions, such as error reporting, available tothe operator. Keyboard 12 allows the operator to make manual input tolibrary 1, such as in response to information received via console 11.Console 11 and keyboard 12 are linked to GLFS 50 by console driver 81and console logical manager 83. The network is linked to LAN adapterdriver 82 and NETBIOS network control program 84. The network interfaceallows a processor on the network to remotely gain access to library 1,which acts as a file server thereto.

GLFS request manager 52 is the interface to operating system 51 andresponds to the same set of entry points that the OS/2 operating systemuses to communicate with any IFS. GLFS request manager 52 is responsiblefor breaking down operating system commands to accomplish libraryfunctions, which it does by calling routines found in the processcontrol manager (PCM) 53a to accomplish each step. PCM 53a is a set ofutility routines, some of which require the generation of requestblocks, that assist the system in breaking down and processing commands.The routines parse directory path strings, enter optical disks into thelibrary, locate volumes, allocate drives to a volume, flip optical disksso as to present the volume on the opposite side for mounting, mountvolumes, demount volumes, exit optical disks from the library etc. andwill be described further where appropriate. The directory managementscheme (DMS) 53b is a module of code which satisfies the IFS filespecification for monitoring the open/closed status of the user files inlibrary 1, as is well known, and is used to manipulate such user files.Use of the IFS interface in such an internal module allows for easyadaptation of external IFS-style implementations of directory managementschemes.

The power on initialization (POI) module 54 manages the power on andreset functions of the controller and is invoked by operating system 51at initialization. POI module 54 is responsible for functions such asdetermining and reporting the results of component self-testing andreading the library configuration and status files. Errors are processedby an error recovery module 56 and an error logging module 57. Recoverymodule 56 processes all errors, including dynamic device reallocationand retries of device commands. Logging module 57 is responsible forsaving error information and reporting it to the operator via console11.

A resource manager 60 dynamically allocates and deallocates controlblocks in the data area of system controller 17, including requestblocks, drive control blocks, and error information blocks. Requestblocks are used to request a hardware event for drives 4 or picker 5.Drive control blocks are used to store status information relating todrives 4, as will be described later herein. Error information blocksare used to store the information needed to report, isolate, andpossibly retry an error. The allocation and deallocation of controlblocks is accomplished using a list of the free space available in themain memory of the IBM PS/2 model 80 personal computer maintained byresource manager 60. Note that both error recovery module 56 andresource manager 60 are connected to most of the components of systemcontroller 17 shown in FIG. 6, such connections not being shown forsimplification.

The schedulers 61 and 62 are responsible for verifying some of thecontents of the request blocks and entering them into the pipe for thehardware device that will process the request. A pipe is a queued datapath leading from one thread to another and can be accessed by anythread knowing the assigned identifier of the pipe. The dispatchers 63and 64 are responsible for validating the request blocks, ensuring thatthe requests are ready to be executed, and dispatching the request asappropriate to the drive logical manager 91 and the library logicalmanager 92. The coordinator 65 is responsible for coordinating requestexecution for dispatchers 63 and 64. The coordinator accomplishes suchusing a table having an entry for each request block received from PCM53a. Each entry lists the supporting request blocks associated with aparticular request block. A request requiring the prior completion ofanother request is referred to as "dependent", the request that mustfirst be completed is referred to as "supporting". Coordinator 65withholds execution of dependent request until associated supportingrequests have been executed. If a supporting request fails executioncoordinator 65 rejects requests dependent thereon.

Logical managers 91 and 92 are responsible for translating the genericlibrary commands in the form of request blocks into the equivalentdevice level commands in the form of SCSI data packets. Logical managers91 and 92 are also responsible for receiving hardware status informationfrom the drive driver 93 and the library driver 94 respectively. Drivers93 and 94 directly manipulate the hardware and physical memory. Drivers93 and 94 perform all communications with their respective hardware andalso respond to interrupts. Logical manager 91 and drive driver 93control drives 4, logical manager 92 and library driver 94 controlpicker 5. Although not shown in FIG. 6 for simplicity, there areactually multiple drive dispatchers 63, drive logical managers 91, anddrive drivers 93--one set for each drive 4 or 10 in library 1. Each setis connected to a different data pipe.

METHOD OF OPERATION

Initialization of library 1 is accomplished using operating system 51,GLFS request manager 52, resource manager 60, and POI module 54. Afterself-testing of the library hardware to verify correct function,operating system 51 is loaded and uses the OS/2 CONFIG.SYS file to setthe operating system parameters and load drivers. Operating system 51then generates an initialization command which is passed to GLFS requestmanager 52 and then on to POI module 54. POI module 54 reads the libraryconfiguration, map, and system performance files, creates necessaryinternal data structures in the main memory of the IBM PS/2 model 80personal computer, and initiates separate threads for each hardwarecomponent of library 1 specified in the library configuration file.Resource manager 60 initializes internal tables used in memorymanagement. POI module 54 then queries system controller 17 andcontroller cards 13 and 18 for power-on self-test results and reportsany problems to error recovery module 56. Any errors detected duringinitialization are logged by error logging module 57 and, if possible,recovered by error recovery module 56. When system controller 17 is in aready state, the system is receptive to activity from console 11 or thenetwork interface.

Referring to FIG. 8, the internal data structures include the opticallibrary main system control block (OLMSCB) 110, one or more librarycontrol blocks (LCB) 111, fixed drive control blocks (DCB) 112, anactive DCB pointer array 113, active DCBs 114, and an optical disk map115. Pointers are represented by arrows in FIG. 8. OLMSCB 110 includesthe number of physical boxes in library 1, the virtual drive optionparameter U, minimum virtual drive eligibility time V, a pointer to theoptical disk map, and a pointer to a LCB 111 for each physical box inlibrary 1 (for convenience, only one such LCB is shown in the drawing).Each LCB 111 includes for the respective physical box the operationalstatus of picker 5 (on-line, off-line, failed), the number of drives 4and 10 therein, the SCSI address of picker 5 therein, the number ofstorage cells 3 therein, the address of each storage cell 3 and slot 9therein, the minimum demount eligibility time W, the preemptive demounteligibility time X, the idle demount time Y, and a pointer to fixed DCBs112 for each drive 4 or 10 therein. Each LCB 111 also includes a pointerto active DCB pointer array 113, which in turn includes a pointer to anactive DCB 114 for each drive 4 or 10 therein.

Five fixed DCBs 112 are shown in the drawing, one for each drive 4 anddrive 10 in the preferred embodiment. Each fixed DCB 112 includescertain drive specific information about drives 4 and 10 which is"fixed" in that it does not change as optical disks are manipulatedabout library 1. Such information includes for the respective drive theoperational status of the drive including a usage attribute indicatingwhether use of the drive is restricted to certain functions (such aswrite only). Fixed DCBs 112 are used as permanent records of suchinformation to create active DCBs 114 as optical disks are manipulatedabout library 1, as will be described.

Six active DCB pointers 113 and active DCBs 114 are shown in thedrawing, one for each drive 4 and drive 10 in the preferred embodiment,and one for the virtual list, which is a linked list of the accessrecords for certain volumes, as will be described. Active DCBs 114include certain volume specific information about drives 4 and 10 andthe virtual accesses. The information is "active" in that it does change(i.e. it is updated) as optical disks are manipulated about library 1.Such information includes for the respective drive or virtual access theappropriate information from fixed DCBs 112 and also the occupancystatus of the drive (whether or not there is an optical disk mountedtherein), usage statistics such as the last access time and user countfor a volume therein or virtual access, and an index into the opticaldisk map for the entry therein which describes the volume mounted in thedrive or virtual access. The index into the optical disk map is used byDMS 53b to locate a volume in library 1, as required. The user count isthe number of current accesses ongoing for a volume, an access being anopen file or any standard operating system command not requiring that afile be opened, such as a directory read.

Optical disk map 115 includes an entry for each storage cell 3 inlibrary 1. An entry for an empty storage cell 3 is blank. An entry for afull storage cell 3 lists the owner of the disk therein, the homestorage cell 3 and current location of the disk, and for each volume onthe disk, the volume label, the number of mounts, the available freespace, and other usage statistics. The aforementioned data structuresalso include other information required for the operation of library 1,although not explicitly described for simplicity, as is known in theart.

Referring to FIG. 9, the operations of system controller 17 will now bedescribed. When a request is received from the network interface, thenetwork control code will convert the request into a set of standardOS/2 operating system commands at step 100. Operating system 51 willthen issue the appropriate operating system calls to process theoperating system commands at step 101. GLFS request manager 52 receivesthe calls and breaks them down into simpler functions. For eachfunction, GLFS request manager 52 will call a routine in PCM 53a and/orDMS 53b and pass the appropriate subset of the data required for theroutine as parameters at step 102. For each routine requiring hardwareactivity, PCM 53a and/or DMS 53b at step 103 calls resource manager 60to create a hardware level request block, issues such block toschedulers 61 and 62, and informs coordinator 65 of any hardwaredependencies to allow for the proper sequencing of the requests. PCM 53aalso returns control and status information to GLFS request manager 52as each routine is completed.

After checking the list of free space available in the main memory ofthe IBM PS/2 model 80 personal computer, resource manager 60 allocatesthe required memory space for the request block. The routines callingresource manager 60 provide most of the information for a control block,resource manager 60 fills in certain additional information such as acontrol block identifier and a request block identifier. Drive scheduler61 and library scheduler 62 receive all hardware event requests asrequest block identifiers and forward them to the data pipes connectedto drive dispatcher 63 and library dispatcher 64 respectively.Dispatchers 63 and 64 continually check their respective data pipe forthe existence of a request block identifier. After receiving a requestblock identifier, dispatchers 63 and 64 call coordinator 65 to determineif the request block is ready to be executed. Coordinator 65 checks thetable of request block dependencies and prevents dispatchers 63 and 64from issuing the request block identifier until all supporting requestblocks have been completed. When all request block dependencies havebeen met, the request block identifier is issued to the respectivelogical manager 91 or 92.

At step 104, logical managers 91 and 92 receive the request blockidentifiers, construct the necessary SCSI hardware command packets toaccomplish the requests, and issue the packets to drivers 93 and 94. Thehardware then physically performs the requests. As each request iscompleted logical managers 91 and 92 signal such completion. Dispatcher63 or 64 then issues the identifier of the next request block to therespective logical manager 91 or 92.

Generally, library mount/demount operations will continue on an asneeded basis as long as there are existing requests to mount volumes.When a volume is first mounted in a drive 4 or 10, an active DCB 114pertaining to the access of such volume is created. The active DCB iscreated by copying the drive specific information relating to the drive4 or 10 in which the volume is mounted from the fixed DCB 112 into ablock of memory and adjusting the appropriate pointers. During access tothe volume, the volume specific information about such access is updatedand stored in the active DCB 114. If the volume is demounted, the volumespecific information is deleted from active DCB 114, except for theoccupancy status information, to indicate that the respective drive 4 or10 is again empty. When a volume is again mounted in the respectivedrive 4 or 10, the active DCB 114 is again updated as necessary with theappropriate volume specific information, and so on.

Volumes are demounted to free a drive 4 to service an existing mountrequest, thereby maintaining drives 4 in an occupied state. Suchoccupancy maximizes the amount of data ready for access. When there areno pending mount requests, however, drives 4 may be preemptivelydemounted to ensure the existence of an unoccupied drive 4 to serviceforthcoming mount requests, and to reduce aging of drives 4 during idleperiods. If all drives 4 are occupied, one drive 4 may be emptied, aswill be described. In addition, the activities of drives 4 areperiodically reviewed to determine if the volumes in any of the occupieddrives 4 should be preemptively demounted because library 1 isrelatively idle, as will also be described. During normal libraryoperations a drive 4 will therefore be empty only after the preemptivedemount of a volume. The criteria for selecting volumes for preemptivedemount when all drives 4 are occupied and there is no pending mountrequest is different from those criteria used during the periodic reviewof the activity of drives 4.

A drive 4 can physically write to or read from only one optical disk atany given time. A request to mount a volume at a time when there are nounoccupied drives 4 normally results in the rejection of the request.However, when the virtual drive option is enabled by setting the virtualdrive option parameter U to one, a request to mount a volume when alldrives 4 are occupied allows for access to more volumes than there aredrives 4 by temporarily demounting the least recently used volume. Thetemporarily demounted volume is referred to as "swapped out" and thenewly mounted volume is referred to as "swapped in". The drive specificinformation for the drive 4 is deleted from the active DCB 114 but thevolume specific access information for the temporarily demounted volumeis retained therein. The active DCB 114 for the temporarily demountedvolume is then retained in a special form of active DCB 114 referred toas the virtual list. The virtual list DCBs differ from other active DCBsin that they contain pointers to each other to create a linked list. Thevirtual list permits resumption of the operations on the volume byremounting at the next volume mount request or, alternatively, cachingcan be used to continue access without remounting. Upon remounting ofthe volume, the appropriate virtual list DCB is deleted from the linkedlist and the volume specific information copied into the active DCB 114for the appropriate drive 4. Because such access information isretained, a volume that has been swapped out under the virtual driveoption is still considered active and under access. Also, remounting ofa volume that has been swapped out can occur in any drive 4 so long asthe access information is provided to the active DCB 114 for therespective drive; a volume access is not tied to the original drive 4 inwhich the volume is mounted. A volume that has been swapped out will notlogically appear to be in its home storage cell 3 as remounting must bedistinguished from the mounting of a volume that has not been swappedout. The actual number of drives 4 in the library is thus transparent tousers. In alternative embodiments, additional virtual eligibility optionparameters can be used to specify only certain volumes as eligible forswapping to prevent churn for volumes frequently accessed.

Referring to the drawing, the high level operations of system controller17 will now be described in further detail beginning at a representativeIFS entry point into GLFS 50 requesting access to a specific, designatedvolume. The description refers to a series of routines of PCM 53a. ThePARSE routine is used to separate volume label 36 from the remainder ofthe path in the request. The READY VOLUME routine is used to determinethe subsequently required operations depending upon the location of thedesignated volume. The IN CELL, IN DRIVE, and SWAP routines are calleddepending upon the location of the designated volume. The IN CELLroutine is called if the designated volume is in its home storage cell3. The IN DRIVE routine is called if the optical disk including thedesignated volume is already mounted in a drive 4. The SWAP routine iscalled if the designated volume is currently active, but has beenswapped out of a drive 4 according to the virtual drive option.

The ALLOCATE and FORCE ALLOCATE routines are called by the IN CELL, INDRIVE, and SWAP ROUTINES as needed. The ALLOCATE routine is used toreserve an unoccupied drive 4 for the mounting of the volume designatedin the request. The FORCE ALLOCATE routine is used to reserve anoccupied drive 4 for the mounting of the volume designated in therequest under the virtual drive option (i.e. by swapping in). The MOUNTroutine simply causes picker 5 to retrieve a volume, mount it in a drive4, and spin it up. The DEMOUNT routine simply causes a mounted opticaldisk to be spun down, to be demounted by picker 5, and transferred toits home storage cell 3. The MOUNT and DEMOUNT routines include updatingof the internal data structures as required and return an error messageif they fail to mount or demount a volume, respectively. The RELEASEVOLUME routine is called after the request is processed to determine ifpreemptive demounting of a volume is appropriate even though library 1is not idle. The IDLE DEMOUNT routine periodically reviews theactivities of drives 4 to determine if any optical disks mounted thereinare sufficiently idle as to be preemptively demounted to reduce aging ofdrives 4.

The following description of the aforementioned routines has beensimplified wherever possible for convenience to eliminate featuresalready described herein or known in the art. For example, theinformation in OLMSCB 110, LCB 111, DCBs 112 and 114, and optical diskmap 115 are not always referenced as their location, content, and usehave already been described. Similarly, information determined during aroutine may be passed on to other routines as such other routines arecalled, as required for the routines being called to execute. Also, theterm "return" is used to refer to an exit from a routine back to thestep which called that routine, including some indication to the callingstep of the result of the routine. Specific error messages are notprovided, but are indicative of the cause of the error. The term"unavailable" is used to refer to a component with an off-line, failed,or locked status, thereby preventing its use. A drive is also consideredto be unavailable if its usage attribute is incompatible with thatrequired for a particular request. Finally, references to external drive10 or the need to flip an optical disk over to ensure mounting of thedesired volume have been eliminated for simplification.

Referring to FIG. 10, the request to access a designated volume isreceived from operating system 51 by GLFS request manager 52 at step200, which then directs steps 201-210 by calling various PCM 53aroutines. At step 201, the PARSE routine is called to extract the volumelabel therefrom and locate the designated volume using the optical diskmap. Step 202 branches according to the result of the PARSE routine. Ifthe PARSE routine returns an error message (i.e. is not successfullycompleted) such error message is returned at step 210. If the PARSEroutine is successful, step 203 branches according to the location ofthe designated volume. If the designated volume is not located inlibrary 1, such volume cannot be accessed therein. The flow thereforeskips to step 210 and an error message is returned. If the designatedvolume is located in library 1, the READY VOLUME routine is called atstep 204. Upon completion of the READY VOLUME routine, step 205 branchesaccording to the result of the READY VOLUME routine. If the READY VOLUMEroutine returns an error message (i.e. is not successfully completed)such error message is returned at step 210. If the READY VOLUME routineis successful, operations on the designated volume according to therequest occur at step 207. When such operations complete, the RELEASEVOLUME routine is called at step 208 to determine if preemptivedemounting is required. When the RELEASE VOLUME routine completes, theresult is returned at step 210.

Referring to FIG. 11, the PARSE routine called at step 201 begins atstep 250. Step 251 `ranches according to the validity of the pathspecified in the request. The validity of the specified path isdetermined by comparing it to the standard path protocol describedearlier. For example, an invalid path format would be one in which thefirst path element is longer than that permitted for volume labels. Ifthe path format is invalid, the flow skips to step 260 and an errormessage is returned. If the path format is valid, the first path element(i.e. the volume label 36) is extracted from the path specification andstored at step 252. At step 253, the remaining path elements are shiftedto eliminate the first path element from the path specification. Theremaining path specification now includes designator 35, subdirectoryelements 37, and filename and extension 39. Step 254 branches accordingto the existence of subdirectory elements 37 in the remaining pathspecification. If subdirectory elements 37 remain, the flow skips tostep 257. If no subdirectory elements remain, the global indicator "*.*"is appended to the path specification at step 256. At step 257, the pathspecification and the optical disk map are used to locate the specifiedvolume in library 1. The existence of the global indicator means that nosubdirectories were specified in the request; the entire library 1 mustbe checked to determine the location of the specified volume. When thePARSE routine completes, the result is returned at step 260.

Referring to FIG. 12, the READY VOLUME routine called at step 204 beginsat step 300 and proceeds along different paths depending upon thelocation of the designated volume. Step 301 branches according towhether the designated volume is currently located in its home storagecell 3. If the designated volume is located in its home storage cell 3,steps 302 and 303 then branch according to whether the request is a newaccess for the requesting user to the designated volume and according towhether picker 5 is available. If the request is not a new access, or ifpicker 5 is unavailable, the flow skips to step 320 and an error messageis returned. An error message is returned because the designated volumeshould not be in its home storage cell 3. A volume that is physicallybut not logically located in its home storage cell 3 (because it isswapped out of a drive 4) will result in step 301 branching to step 307.If the picker 5 is unavailable, an error message is returned at step 320because mounting of the designated volume cannot occur. If the requestis a new access, and picker 5 is available, the IN CELL routine iscalled at step 306 to attempt to mount the designated volume in a drive4. Upon completion of the IN CELL routine, the READY VOLUME routinereturns at step 320.

If the designated volume is not located in its home storage cell 3 atstep 301, the search to locate the current position of such volumecontinues at step 307. Step 307 branches according to whether theoptical disk including the designated volume is already in a drive 4. Ifsuch optical disk is in a drive 4, no mount operations are required andthe IN DRIVE routine is called at step 308. Upon completion of the INDRIVE routine step 309 branches according to whether the request is anew access for the requesting user to the designated volume. If therequest is not a new access, the flow skips to step 320. If the requestis a new access, the user count of the designated volume is incrementedat step 310. The READY VOLUME routine returns at step 320.

If the optical disk including the designated volume is not in a drive 4at step 307 (the designated volume is already known to be in library 1,but has not been located in its home storage cell 3 or a drive 4), itshould have been swapped out of a drive 4 according to the virtual driveoption. Steps 312 and 314 branch according to whether the designatedvolume is located in the virtual list and according to the availabilityof picker 5. If the designated volume is not located in the virtuallist, or if picker 5 is unavailable, an error message is returned atstep 320. If the designated volume is not located in the virtual list,an error message is returned because such volume cannot be located. Ifpicker 5 is unavailable, an error message is returned because mountingof the designated volume cannot occur. If the designated volume islocated in the virtual list, and if picker 5 is available, the SWAProutine is called at step 316. Upon completion of the SWAP routine theREADY VOLUME routine returns at step 320.

Referring to FIG. 13, the IN CELL routine called at step 306 begins atstep 400 and proceeds along different paths depending upon the existenceof an unoccupied drive 4 in which to mount the volume. At step 401, theALLOCATE routine is called to reserve a drive 4 for mounting of thevolume designated in the request. Step 402 branches according to theresults of the ALLOCATE routine. If an unoccupied drive 4 is located andreserved (i.e. the ALLOCATE routine succeeded), the MOUNT routine iscalled at step 409 to mount the designated volume in the reserved drive4. If an unoccupied drive 4 is not located and reserved (i.e. an errormessage is returned), step 404 branches according to whether the virtualdrive option is enabled. If the virtual drive option is not enabled, theflow skips to step 410 and the result of the ALLOCATE routine isreturned. If the virtual drive option is enabled, the FORCE ALLOCATEroutine is called at step 406. Although no unoccupied drive 4 exists,the virtual drive option allows for the swapping in of the designatedvolume. At step 407, branching occurs to the result of the FORCEALLOCATE routine. If the FORCE ALLOCATE routine returns an errormessage, such result is returned at step 410. If the FORCE ALLOCATEroutine successfully swaps out the designated volume, the MOUNT routineis called at step 409. Upon completion of the MOUNT routine the IN CELLroutine returns at step 410.

Referring to FIG. 14, the IN DRIVE routine called at step 308 begins atstep 420 and proceeds along two basic paths depending upon theavailability of the drive 4 in which the designated volume is mounted.Step 421 branches to step 422 if the drive 4 in which the designatedvolume is mounted is unavailable. Step 422 then branches according towhether picker 5 is available. If picker 5 is unavailable, the flowskips to step 442 and an error message is returned. An error message isreturned because the designated volume cannot be accessed in anunavailable drive 4 and cannot be transferred to another drive 4 aspicker 5 is also unavailable. If picker 5 is available at step 422, theSWAP routine is called at step 425 to swap the designated volume out ofdrive 4. Upon completion of the SWAP routine, the READY VOLUME routineis called at step 426. Upon completion of the READY VOLUME routine, theIN DRIVE routine returns at step 442.

If at step 421 the drive 4 in which the designated volume is mounted isavailable, step 433 branches according to whether the designated volumeis located in the virtual list. If the designated volume is located inthe virtual list, the flow skips to step 441 to call the SWAP routine toattempt to swap in the designated volume. The swap routine is calledbecause the optical disk including the designated volume is in a drive4, but the designated volume is swapped out of such drive 4. If thedesignated volume is not located in the virtual list, branching occursat step 434 according to whether the request is a new access for therequesting user to the designated volume. If the request is not a newaccess, an error message is returned at step 442. If the request is anew access, steps 437 and 438 branch according to whether the virtualdrive option is enabled and according to whether the designated volumeis active (i.e. has a positive user count). If the virtual drive optionis not enabled and the designated volume is active, an error message isreturned at step 442. Otherwise, the user count of the designated volumeis incremented at step 440 and the SWAP routine is called at step 441.Upon completion of the SWAP routine, the IN DRIVE routine returns atstep 442.

Referring to FIG. 15, the SWAP routine begins at step 450 and branchesat step 452 according to the need to allocate a drive. If no drive 4needs to be allocated, the flow continues at step 463. Step 463 branchesaccording to whether the request is a new access for the requesting userto the designated volume. If the request is not a new access, the flowskips to step 466. If it is a new access, the user count for thedesignated volume is incremented at step 464 before proceeding to step466. If at step 452 a drive 4 needs to be allocated, the ALLOCATEroutine is called at step 453. Step 454 branches according to theresults of the allocate routine. If the ALLOCATE routine succeeds inlocating and reserving an unoccupied drive 4, the flow skips to step466. If the ALLOCATE routine returns an error message, step 457 branchesaccording to the whether the virtual drive option is enabled. If thevirtual drive option is not enabled, the flow skips to step 487 and theresult of the ALLOCATE routine is returned. If the virtual drive optionis enabled, the FORCE ALLOCATE routine is called at step 459. Step 461then branches according to the results of the FORCE ALLOCATE routine. Ifthe FORCE ALLOCATE routine returns an error message, the error messageis returned at step 487. If the FORCE ALLOCATE routine succeeds, theflow continues at step 466.

At step 466, branching occurs according to whether the designated volumeis already mounted in the allocated drive 4. If the designated volume isalready mounted in the allocated drive 4, the flow skips to step 481. Ifthe designated volume is not already mounted in the allocated drivedrive 4, branching occurs at step 468 depending upon the occupancystatus of such drive 4. If such drive 4 is unoccupied, the flow skips tostep 474. If such drive 4 is occupied, the optical disk therein isdemounted by a call to the DEMOUNT routine at step 469. Step 471branches according to the results of the DEMOUNT routine. If the DEMOUNTroutine returns an error message, the error message is returned at step487. If the DEMOUNT routine succeeds, the flow continues with a call tothe MOUNT routine at step 474. At step 476, branching occurs accordingto results of the MOUNT routine. If the MOUNT routine returns an errormessage, the error message is returned at step 487. If the MOUNT routinesucceeds in mounting the designated volume, branching occurs at step 481according to the activity status of any volume demounted from theallocated drive 4 at step 469. If the user count of the demounted volumeis positive, the volume specific information in active DCB 114 for theallocated drive 4 for such volume is retained by linking it into thevirtual list at step 482 and the flow continues at step 484. If the usercount of the demounted volume is not positive, the information in activeDCB 114 is discarded at step 483 and the flow continues at step 484. Atstep 484, the volume specific information in the virtual list for thedesignated volume is copied into active DCB 114 for the allocated drive4. At step 486, the information in the virtual list for the designatedvolume is deleted and the flow returns at step 487. Note that becauseactive DCBs 114 are updated as required at steps 482-484 and 486, suchupdating otherwise performed during the MOUNT and DEMOUNT routines isinhibited at the calls to such routines at steps 469 and 474.

Referring to FIG. 16, the ALLOCATE routine begins at step 500 andbranches at step 502 according to the existence of an empty, availabledrive 4 in which to mount the designated volume. If there is an empty,available drive 4, the user count for the designated volume isincremented at step 503 in preparation for its being mounted in suchdrive 4 and the flow skips to step 513. The empty, available drive 4 isat this point reserved for such mounting. If there is more than oneempty, available drive, the first such drive located by examining theinternal data structures of library 1 is allocated. In alternativeembodiments, the choice among multiple empty, available drives could bemade using any known scheduling technique, such as FIFO, LIFO, roundrobin, or minimum picker travel techniques. If there is no empty,available drive 4, steps 506 and 507 branch according to the existenceof an available, inactive drive 4 and whether any such inactive drive 4has been active in the last minimum demount eligibility time W. If thereis no available, inactive drive 4, or if such a drive 4 is located buthas not been inactive for time W, the flow skips to step 513 and anerror message is returned. If there is no available, inactive drive 4,an error message is returned as there is little benefit to interruptingthe activity of one of the drives 4 to demount the optical disk thereinand subsequently mount the designated volume. If there is an available,inactive drive 4, but no such inactive drive 4 has been inactive fortime W, no optical disk is demounted and an error message is returned,thereby preventing churn during piecewise active system applications. Ifthere is an available, inactive drive 4 that has been inactive for timeW, the DEMOUNT routine is called to demount the optical disk therein atstep 511. If more than one such drive 4 is located, the optical disk inthe drive 4 that has been inactive the longest (i.e. the least recentlyused optical disk) is demounted. At step 512, the user count for thedesignated volume is incremented in preparation for its being mounted.The ALLOCATE routine returns at step 513.

Minimum demount eligibility time W can be tailored to the operatingcharacteristics of the particular library and its operating environment.When W is zero, step 507 will always branch to step 511 for demounting.The risk is that demounting may occur only to have remounting of thedemounted optical disk required shortly thereafter. When W is verylarge, disks may never be demounted as is desired. In the preferredembodiment W is set to between 0 and 10 seconds to maintain the properbalance among these factors.

Referring to FIG. 17, the FORCE ALLOCATE routine begins at step 520 andbranches according to the existence of an available, inactive drive 4 atstep 522. If there is no availablem inactive drive 4, the flow skips tostep 530 and as there is little benefit to interrupting the activity ofone of the drives 4 to demount the optical disk therein and subsequentlymount the designated volume. If there is an available, inactive drive 4,steps 524 and 526 branch according to whether any inactive drive 4 hasbeen active in the last minimum demount eligibility time W seconds orwhether any inactive drive 4 has been active in the last minimum virtualdrive eligibility time V. If no inactive drive 4 has been inactive forthe time W and the time V, an error message is returned at step 530. Anerror message is returned because the risk of churn is considered toohigh to demount an optical disk. If there is a drive 4 which has notbeen active within time W and time V, the user count for the designatedvolume 4 is incremented at step 528 in preparation for its beingmounted. At step 529, the SWAP routine is called. Upon completion of theSWAP routine, the FORCE ALLOCATE routine returns at step 530.

Minimum virtual drive eligibility time V can be tailored to theoperating characteristics of the particular library and its operatingenvironment. When V is zero, step 526 will always branch to steps 528and 529 to call the SWAP routine to attempt to demount an optical diskunder the virtual drive option. The risk is that demounting may occuronly to have remounting of the demounted optical disk required shortlythereafter. When V is very large, step 526 will always branch to step530, thereby returning from the FORCE ALLOCATE routine. Such a largevalue of V effectively eliminates the FORCE ALLOCATE routine. In thepreferred embodiment V is set to between 0 and 30 seconds to maintainthe proper balance among these factors.

Referring to FIG. 18, the RELEASE VOLUME routine called at step 208begins at step 350. Step 351 branches according to the activity of thedrive 4 in which the designated volume has been mounted. If the drive 4is active, the flow skips to step 358. If the drive 4 is inactive, theuser count for the drive 4 is decremented at step 352 to reflect theinactivity. Step 353 then branches according to whether the designatedvolume is actually mounted in a drive 4 or is swapped out under thevirtual drive option. If the designated volume is actually mounted in adrive 4, the flow skips to step 358. If the designated volume is swappedout under the virtual drive option, branching occurs at step 354according to the activity status of the designated volume. If the usercount of the designated volume is positive, the flow skips to step 358.If the user count of the designated volume is zero, the accessinformation in the virtual list is no longer required and is discardedat step 356 before proceeding to step 358.

Steps 358-364 determine whether any optical disks in library 1 should bepreemptively demounted. Branching occurs at step 358 according to theexistence of an available, unoccupied drive 4 in library 1. If there isan available, unoccupied drive 4, the flow skips to step 365 and theRELEASE VOLUME routine returns. Demounting is not required as anunoccupied drive 4 already exists to service a future mount request. Ifall drives 4 are occupied, the index into the optical disk map for theleast recently used volume mounted in an available drive 4 is retrievedat step 361. Branching then occurs at step 362 according to whether suchleast recently used volume has been active within the last preemptivedemount eligibility time X. If such volume has been active in the lasttime X, demounting is not performed as the risk of churn is consideredto be too great and the flow skips to step 365. If such volume has notbeen active in the last time X, the DEMOUNT routine is called to demountthe optical disk including such volume at step 364 before proceeding tostep 365. Because accessing data is often associated with accessing datastored nearby, the least recently used volume is considered to be themounted volume least likely to be accessed nest (i.e. the mounted volumeleast likely to result in churn if demounted). Demounting ensures thatan empty drive 4 is available to service the next mount request. Notethat the existence of a pending mount request has no relevancy to steps358-364. Even when no mount request is pending an optical disk can bedemounted (i.e. "preemptively" demounted) in anticipation of a futuremount request. In alternative embodiments, more than one drive 4 may beemptied when all drives 4 are occupies, but such is not preferred as itunduly reduces the number of optical disks remaining on-line (i.e.mounted and spinning). Upon completion, the RELEASE VOLUME routinereturns at step 365.

Preemptive demount eligibility time X can be tailored to the operatingcharacteristics of the particular library and its operating environment.When X is zero, step 362 will always branch to step 364 for preemptivedemounting. The risk is that demounting may occur only to haveremounting of the demounted disk required shortly thereafter. When X isvery large, disks may never be preemptively demounted as is desired. Toprevent the demounting at step 511 of most disks otherwise eligible forpreemptive demounting at step 364, X should be greater than or equal toW. In the preferred embodiment X is set between 0 and 20 seconds tomaintain the proper balance among these factors. Where X is less than W,step 362 should branch according to whether the least recently usedvolume has been active within W and X. Branching to step 364 should onlyoccur if the least recently used volume has not been active in the lasttime W and the last time X.

Referring to FIG. 19, the periodic review of the activities of drives 4to determine if the optical disk in any of occupied drives 4 issufficiently idle as to be preemptively demounted begins with theperiodic interruption of console 11 at step 600. In the preferredembodiment console 11 is interrupted every 10 seconds. The interruptsare issued without regard to the status of library 1 with respect toFIGS. 8-15. At step 601, branching occurs according to the activitystatus of drives 4 as in step 362, except that the preemptive demounteligibility time X is replaced with a relatively much larger idledemount time Y. If no drive 4 has been inactive for time Y, the flowreturns at step 605. Note that because the time Y is much greater thanthe time X, the determination not to preemptively demount at step 601has little, if anything, to do with the risk of churn.

If at step 601 any drive has been inactive for time Y, the DEMOUNTroutine is called at step 602 to preemptively demount all optical disksmounted in any such inactive drive 4 before proceeding to step 605. Theexistence of a drive 4 that has been inactive for time Y is consideredto be an indication that library 1 is relatively idle. Idle periods mayoccur during periods of low overall system use, such as nights andweekends in some data processing systems. At such times, it is notdesirable to continue to spin the optical disks in drives 4. So long asdisks are spinning, the lasers in drives 4 will continue to follow thetracks on the disks, resulting in needless servo action. The drivemotors and lasers will work to maintain drives 4 in a state of readinesseven though no useful work is being performed, thereby prematurely agingdrives 4. Note that preemptive demounting here applies to all opticaldisks mounted in such inactive drives, not just the least recently useddisk, as the need to reduce aging of the drives is considered tooutweigh the need to maintain disks on-line when library 1 is relativelyidle. Thus, by preemptively demounting certain disks during relativelyidle periods, the reliability of library 1 is improved. In analternative embodiment, the reliability of library 1 could be improvedby spinning down such disk without their being demounted and returned totheir home storage cell 3.

Idle demount time Y can be tailored to the operating characteristics oflibrary 1 and its operating environment. When Y is zero, the opticaldisk in any inactive drive 4 will be preemptively demounted from suchdrive 4. The risk is that preemptive demounting of several disks mayoccur just before the activity in library 1 increases. When Y is verylarge, disks may never be preemptively demounted. Such a large value ofY effectively eliminates the IDLE DEMOUNT routine. In the preferredembodiment, Y is set between 10 and 30 minutes to maintain the properbalance among these factors. In an alternative embodiment, no drive 4 ispreemptively demounted unless one or more drives 4 are unoccupied andone or more of the mounted drives 4 has been inactive for time Y. Theexistence of an unoccupied drive 4 would result from preemptive demountoperations at steps 358-364. The addition of the need for an unoccupieddrive 4 to qualify library 1 as relatively idle reduces the likelihoodthat demounting under the IDLE DEMOUNT routine will occur just beforethe activity in library 1 increases.

In an alternative embodiment, library 1 can be set to operate in "fixed"mode or "adaptive" mode, as designated in the system performance fileand OLMSCB 110. In fixed mode, library 1 operates as previouslydescribed. In adaptive mode, the operator specifies times W, X, and Yand adaptive mode time Z. Z is a predetermined time for comparison withthe time since an optical disk was last demounted. At mounting, if thetime since a disk was last mounted is less than Z, the remounted disk isconsidered to be a relatively active disk which cannot be preemptivelydemounted according to steps 358-364. Demounting of such a disk onlyoccurs as part of the ALLOCATE routine to service a pending mountrequest, or as part of the IDLE DEMOUNT routine. At mounting, if thetime since a disk was last mounted is greater than Z, the remounted diskis considered eligible for preemptive demounting according to steps358-364. In adaptive mode a disk can have its eligibility for preemptivedemounting adjusted as the demand for access to such disk varies overtime. The more active disks are dynamically sorted from the less activedisks, thereby further decreasing the likelihood of churn.

Adaptive mode time Z can be tailored to the operating characteristics ofthe particular system. When Z is zero, all remounted disks are eligiblefor preemptive demounting and library 1 operates in fixed mode. When Zis very large, disks are prevented from being preemptively demounted. Inthe preferred embodiment, Z is set between 0 and 120 seconds to maintainthe proper balance among these factors.

While the invention has been described with respect to a preferredembodiment thereof, it will be understood by those skilled in the artthat various changes in detail may be made therein without departingfrom the spirit, scope, and teaching of the invention. For example,while the invention has been disclosed in the context of an optical disklibrary, similar consideration may make it equally applicable to othertypes of libraries. In addition, numerous variations in the librariesmay be made, such as the number of drives and storage cells. Forexample, in an alternative embodiment, library 1 includes 32 storagecells 3 and two drives 4. System controller 17 is located external tohousing 2, which is of reduced size. The remaining features of library 1are essentially unchanged. Accordingly, the invention disclosed hereinis to be limited only as specified in the following claims.

What is claimed is:
 1. A method for servicing a request to mount afirst, unmounted data volume in an automated storage library having aplurality of occupied peripheral storage devices therein, the methodcomprising machine-executed steps of:retaining access information for asecond data volume mounted in a first one of the peripheral storagedevices; physically demounting the second data volume even though accessto the second data volume has not been completed; mounting the firstunmounted data volume in the first one of the peripheral storagedevices; remounting the second data volume in any one of the peripheralstorage devices that subsequently becomes available after a data volumemounted therein is demounted; and resuming access to the second datavolume by recalling the access information for the second data volume.2. The method of claim 1 wherein the aforementioned steps only occur ifa virtual drive option for the automated storage library, indicated by avirtual drive option parameter stored therein, is enabled, the requestto mount otherwise being rejected.
 3. The method of claim 1 wherein theaforementioned steps only occur is a virtual eligibility option for thesecond data volume, indicated by a virtual eligibility option parameterstored in the automated storage library, is enabled, the request tomount otherwise being rejected.
 4. The method for servicing a requestaccording to claim 1 wherein the second data volume is remounted in aperipheral storage device other than the first peripheral storagedevice.
 5. A method for servicing a request to mount a first, unmounteddata volume in an automated storage library when all peripheral storagedevices therein are occupied, the automated storage library includingstorage of a virtual drive option for the automated storage library anda virtual eligibility option for a second data volume mounted in a firstone of the peripheral storage devices, the method comprisingmachine-executed steps of:determining if both the virtual drive optionand the virtual eligibility option are enabled; if both the virtualdrive option and the virtual eligibility option are not enabled:rejecting the request to mount; if both the virtual drive option and thevirtual eligibility option are enabled; retaining access information forthe second data volume; physically demounting the second data volumeeven though access to the second data volume has not been completed;mounting the first data volume in the first one of the peripheralstorage devices; remounting the second data volume in one of theperipheral storage devices that subsequently becomes available after adata volume mounted therein is demounted; and resuming access to thesecond data volume by recalling the access information for the seconddata volume.
 6. An automated storage library comprising:a plurality ofinternal peripheral storage devices, each internal peripheral storagedevice capable of having a data volume mounted therein; a plurality ofstorage cells, each storage cell capable of storing one data storagemedium therein, each data storage medium including at least one datavolume; a picker for transferring a data storage medium between anyinternal peripheral storage device and any storage cell; andmachine-executed means coupled for issuing commands to the picker forservicing a request to mount a first, unmounted data volume in anautomated storage library when all of the peripheral storage devicestherein are occupied, the request serviced by: retaining accessinformation for a second data volume mounted in a first one of theperipheral storage devices; physically demounting the second data volumeeven though access to the second data volume has not been completed;mounting the first data volume in the first one of the peripheralstorage devices; remounting the second data volume in any one of theperipheral storage devices that subsequently becomes available after adata volume mounted therein is demounted; and resuming access to thesecond data volume by recalling the access information for the seconddata volume.
 7. The automated storage library of claim 6 wherein themachine-executed means for servicing a mount request only operates if avirtual drive option for the automated storage library, indicated by avirtual drive option parameter stored therein, is enabled.
 8. Theautomated storage library of claim 6 wherein the machine-executed meansfor servicing a mount request only operates if a virtual eligibilityoption for the second data storage volume, indicated by a virtualeligibility option parameter stored in the automated storage library, isenabled.